home *** CD-ROM | disk | FTP | other *** search
/ C/C++ Users Group Library 1996 July / C-C++ Users Group Library July 1996.iso / vol_200 / 265_01 / letter.txt < prev    next >
Text File  |  1992-07-18  |  6KB  |  140 lines
  1. Rainer Gerhards Baesweiler, MONTHNAME DAY, t="%'", 19YEAR, t="%d"
  2. Petronellastr. 6
  3. D-5112 Baesweiler
  4. West Germany
  5. Phone (49) 2401-1601
  6.  
  7.  
  8.  
  9.  
  10. The C Users Journal
  11. Mr. Robert Ward
  12. 2120 W. 25th St. Ste. B
  13. Lawrence, KS 66046
  14. U S A
  15.  
  16.  
  17.  
  18. Dear Mr. Ward,
  19.  
  20.  CUG Cpio Installation Kit 
  21.  
  22. I'm writing to announce the enhancement of parts of the CUG cpio
  23. installation kit. I've brought some new features to the cpio
  24. archive processing program as well as written two new MS-DOS
  25. driver programs.
  26.  
  27. First of all, my version of cpio now supports two additional
  28. options, allowing even more system-independent archives. The
  29. usage information has also been improved. The new options are "p"
  30. and "d".
  31.  
  32. Option p ignores pathnames stored in the archive file. So
  33. whatever pathname was used during creation of the archive is
  34. ignored on output. However, the pathname is displayed in brackets
  35. for convenience. The p option is currently ignored on input.
  36.  
  37. Option d reflects a change in the internal program philosophy: Up
  38. to now, cugcpio extracted files under all circumstances. If a
  39. file with the same name existed, it was overwritten silently.
  40. Cugcpio now first checks to see if the file exists. If yes, the
  41. user is queried whether or not to overwrite the old one. To
  42. select the former behavior, option d has been added. If d is
  43. specified on the command line, existing files are silently
  44. overwritten. I'd recommend using this option only for extracting
  45. a new version of a program over an old one. Not specifying the
  46. option is much more secure.
  47.  
  48. There are also two new low-level drivers for MS-DOS included.
  49. They are companions to my high-level sector read and write
  50. utilities. These new drivers fix all (at least I hope) problems
  51. we had with the old int 0x25/0x26 ones. The new drivers don't use
  52. MS-DOS but the BIOS to do their work. They are strictly
  53. restricted to the IBM 360KB (2 sides, 40 track, 9 sectors, 512
  54. bytes) format, because they map an relative sector number to its
  55. absolute address.
  56.  
  57. No special tricks (like reading in some information from another
  58. disk) are necessary to operate the sector read/write utilities
  59. using the new drivers. I found them working correctly where the
  60. old ones failed.
  61.  
  62. Although the new drivers completely replace the old ones, you
  63. should retain them for people with generic MS-DOS machines (like
  64. the early Wang PCs). They old drivers work mostly correct on
  65. them, while the new ones totally fail (those machines don't have
  66. an IBM compatible BIOS).
  67.  
  68. And one last word to the driver theme: Mr. Scott Henion's letter
  69. in the November issue gave me an inspiration. I had to realize
  70. that our system-independent file transfer system has one serious
  71. problem. Most operating systems allow  to access disks directly.
  72. But most of them require some control structures on disk to do
  73. so. So what's our fine system worth? As long as you don't find a
  74. person able (and willing) to build an actual device driver for
  75. the target environment... nothing! And I think we've seen that it
  76. is hard to find these persons. However, I hope there'll be
  77. someone out there able and willing to produce sector read/write
  78. routines using native OS calls. But, after all, we aren't able to
  79. use their potential because we've to build extremely complex
  80. device drivers.
  81.  
  82. This way the cpio system wont be a success. Unfortunately the
  83. last few month confirm that. There are only drivers for systems
  84. available that could read your disks ever before. I guess not
  85. even a single percent of your orders is shipped in cpio, while 90
  86. percent are shipped in MS-DOS format. Most members don't accept
  87. the new format because they don't see a direct advantage in using
  88. it. For MS-DOS people the easiest way is to use their native
  89. format. Most other machines require less effort to read MS-DOS
  90. disks than cpio ones. Maybe the files are transferred via
  91. asynchronous communication. All because there's no low-level read
  92. sector driver for them available.
  93.  
  94. In order to become a success, most people have to see advantages
  95. in using the cpio file transfer system. In order to allow this,
  96. we've to have much more sector load utilities for different
  97. environments. In order to get them we've to find people able and
  98. willing to write them. And in order to find them, we've to make
  99. the task of creating such an driver easier.
  100.  
  101. As far as I've thought about it, the actual problem is how to
  102. enable the usage of the OS's native read/write sector calls. I
  103. imagine this can be achieved by writing some of the OS's basic
  104. disk information tables to the cpio exchange disk. I don't think
  105. that's a Herculean work for you. You stated you're able to
  106. physically write and read every format. Given a master disk of
  107. each OS, you could read the very first sectors usually containing
  108. the OS disk bookkeeping information. Written this sectors to the
  109. beginning of the exchange disk, you can satisfy the OS's need for
  110. that information. However, there's no need for being correct
  111. (except for the disk type). The archive still starts as a single
  112. dump file immediately after the control information. The disk
  113. will never be read using target OS file system calls.
  114.  
  115. I think this approach is worth to be discussed, although I know
  116. there are many problems to arise. I also think this approach
  117. might introduce a large overhead to your disk distribution.
  118. Nonetheless, there may be some solutions in between. And I
  119. definitely think that the task of building an system independent
  120. file transfer utility is of huge worth for the whole computer
  121. Industrie, not only the C Users' Group. And as such I think we
  122. should extend our activities to build that system.
  123.  
  124. Enough about that. I've one final request: could you please pass
  125. me one copy of your official cpio installation kit. This enables
  126. me to base my further work in that area on your official system.
  127. As far as I've read, you've build some other loader utility. I
  128. guess I can save you some time if I adapt my low-level drivers to
  129. your high-level program. And I sure want to extend the number of
  130. low-level drivers as soon as I've the necessary opportunities.
  131.  
  132.  
  133.  
  134.  
  135. With that promise, sincerely yours
  136.  
  137.  
  138.  
  139. R. Gerhards
  140.